Interactive message response system for enterprise call routing

ABSTRACT

This invention integrates instant messaging, presence, and other collaborative capabilities with conventional PBX functionality through use of a PBX-Messaging Integration Client (PMIC). The invention in its several embodiments features a method and system for using the PMIC-based computer interface to perform off-hook/on-hook presence notification for a PBX phone, establish media sessions concurrent with PBX telephonic communication, execute custom call treatment in conjunction with a PBX phone, implement call transfer capability between a PBX phone and numerous other devices, and provide PBX call control. The PBX is generally enabled with computer telephony integration (CTI) and, depending on the embodiment, a Voice-over-Internet Protocol (VoIP) such as Session Initiation Protocol (SIP). The invention empowers enterprise workers with a diverse, unified and integrated set of both PBX functions and SIP-based collaboration tools.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of prior application Ser. No.10/750,795 filed Dec. 31, 2003, which is hereby incorporated herein byreference for all purposes.

FIELD OF THE INVENTION

The present invention relates to a technique for integrating one or moreuser interfaces with a PBX phone system. In particular, the inventionrelates to a method and system for providing off-hook/on-hook presencenotification for a PBX phone, establishing media sessions concurrentwith PBX telephonic communication, customized call treatment for a PBXphone, call transfer capability between a PBX phone and numerous otherdevices, and PBX call control.

BACKGROUND

Private Branch Exchange (PBX) telephone systems are used in manybusinesses to enable workers to make and receive calls from the PublicSwitched Telephone Network (PSTN) and other PBX phones within theenterprise. PBX systems also provide a host of telephonic services tothe enterprise workers including call forwarding, transferring,conferencing, voice mail, personalized greetings, and the like.

In many cases, an enterprise worker's phone resides on the desktop inimmediate proximity to the worker's personal computer. The personalcomputer may provide tools for word processing, viewgraph editing,email, and web browsing, as well as other communications tools such asinstant messaging, buddy lists, presence, video, and other tools forcollaboration. Instant messaging allows people with network access tosend text messages and other media to other individuals listed in abuddy or contact list. An instant text message is sent in near-real timeto a contact where it is then displayed in a graphical user interfacewindow within the context of an on-going text-based conversation. Inaddition to text messages, instant messaging may also be used withinchat sessions and custom chat rooms where friends or co-workers caninteract and share media. Some instant messaging applications are alsoenabled with a presence protocol used by a one person to determinewhether a buddy or contact is “present” online and to subscribe tochanges in the presence state or information.

Despite the prevalence of PBX phones and communications-enabled personalcomputers in the enterprise, there is an absence of sufficientintegration between these two types of communication systems. Forexample, an enterprise worker's instant messaging application may beaware of the worker's online presence but is oblivious to the worker'stelephonic presence, i.e. buddies do not know that a worker is occupiedon his PBX phone. Or, as a second example, although a worker sets up avoice session to another worker by dialing a PBX extension, an entirelyseparate process must be followed to setup a session for exchanging adocument. Therefore, there is a need for a solution that integrates thePBX system and communications applications on enterprise workers'computers to provide greater interoperability, simplified PBX control,and enhanced sharing and collaboration.

SUMMARY

The invention in its several embodiments features a method and systemfor using a computer interface to perform off-hook/on-hook presencenotification for a PBX phone, establish media sessions concurrent withPBX telephonic communication, execute custom call treatment inconjunction with a PBX phone, implement call transfer capability betweena PBX phone and numerous other devices, and provide PBX call control.The PBX is generally enabled with computer telephony integration (CTI)capabilities and may also, depending on the embodiment, be enabled withVoice-over-Internet Protocol (VoIP) capabilities such as SessionInitiation Protocol (SIP). The computer interface may be any number ofcomputer appliances including personal computer also enabled with CTI,for example.

In one embodiment, the invention relates to a presence notificationmethod for communicating an enterprise worker's on-phone/off-phonepresence state to other workers using a computer interface operativelycoupled to a system comprising a private branch exchange (PBX) and afirst PBX phone. The presence notification method preferably comprisesthe steps of: receiving from the PBX a first message indicating anoff-hook state of the first PBX phone; consulting a subscriber tableincluding the identity of one or more presence-state subscribers; andtransmitting a second message to at least one of the one or morepresence-state subscribers indicating the off-hook state of the firstPBX phone.

In a second embodiment, the invention relates to a method forestablishing a collateral communication session between a plurality ofenterprise workers' computer interfaces in response to a call betweenthe workers. The collateral communication session, referred to herein asa concurrent media session, may take a number of forms including textmessaging, document exchange, desktop sharing, and video, for example.The method for establishing concurrent media session setup using a firstcomputer interface operatively coupled to a system comprising a privatebranch exchange (PBX) and a second computer interface preferablycomprises the steps of: receiving from the PBX a first messagesignifying that the second PBX phone has called the first PBX phone;transmitting a second message from the first computer interface to thesecond computer interface requesting a media session; determiningwhether the media session request has been accepted at the secondcomputer interface; and establishing a media session between the firstcomputer interface and second computer interface if the session requestmessage is accepted.

In a third embodiment, the invention relates to a method for performingcustom call treatment allowing a recipient of an incoming PBX call torespond to the call by transferring the call to another device orresponding with an instant message, for example, depending on variousfactors including the caller, the time, and date. The call treatmentmethod in a first computer interface operatively coupled to a systemcomprising a private branch exchange (PBX) and a first PBX phonepreferably comprises the steps of: receiving from the PBX a firstmessage indicating an incoming call; determining from a call routingtable maintained by the first computer interface an incoming callresponse to the incoming call; and transmitting a group of one or moremessages based on the incoming call response, wherein the groupcomprises a second message answering the incoming call.

In a fourth embodiment, the invention relates to a method fortransferring a call between an enterprise worker's PBX phone and anassociated computer interface. The call transfer method in a firstcomputer operatively coupled to a system comprising a private branchexchange (PBX) and a first PBX phone, preferably comprises the steps of:transmitting to the PBX a first message for transferring a telephonecall associated with the first PBX phone; establishing a voice-over-IPsession between the PBX and the first computer; and replacing thetelephone call to first PBX phone with a call to the first computer viathe voice-over-IP session.

In a fifth embodiment, the present invention relates to a method ofcontrolling PBX telephone calls to a worker's PBX phone using a computerinterface operatively coupled to a system comprising a PBX and a firstPBX phone. The PBX call control method preferably comprises the stepsof: receiving from the PBX a first message indicating the presence of atelephone call associated with the first PBX phone; and transmitting tothe PBX a call control message, such as a call-hold command, orcall-forwarding command directing the PBX to another PBX phone or VoIPclient, for example.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, and in which:

FIG. 1 is a functional block diagram of an enterprise network includinga PBX system and Internet Protocol (IP) network, according to thepreferred embodiment;

FIG. 2A is a functional block diagram of a PBX, according to thepreferred embodiment;

FIG. 2B is a functional block diagram of a PBX processing module,according to the preferred embodiment;

FIG. 3 is a functional block diagram of a PBX user phone, according tothe preferred embodiment;

FIG. 4A is a functional block diagram of a enterprise worker'sPBX-Messaging Integration Client (PMIC), according to the preferredembodiment;

FIG. 4B is a functional block diagram of a PMIC processing module,according to the preferred embodiment;

FIGS. 5A and 5B is a state diagram characterizing the PBX with which thepreferred embodiment interoperates, according to the preferredembodiment;

FIG. 6 is a flowchart of the PBX external-call-placed processing,according to the preferred embodiment;

FIG. 7A is a flowchart of the PBX internal-call-placed processing,according to the preferred embodiment;

FIG. 8 is a flowchart of the PBX voice-over-IP (VoIP) session setup,according to the preferred embodiment;

FIG. 9 is a flowchart of the PBX call-receiving state processing,according to the preferred embodiment;

FIG. 10 is a flowchart of the PBX call-answered state processing,according to the preferred embodiment;

FIG. 11 is a state diagram characterizing the PBX-Messaging IntegrationClient (PMIC) processing, according to the preferred embodiment;

FIG. 12A is a flowchart of the on-phone presence state processing,according to the preferred embodiment;

FIG. 12B is a flowchart of the off-phone presence state processing,according to the preferred embodiment;

FIG. 13 is a flowchart of the concurrent media session setup procedure,according to the preferred embodiment;

FIG. 14 is flow diagram depicting the method of distributing telephonicpresence-sense notices, according to the preferred embodiment;

FIG. 15 is a flow diagram demonstrating the use of a networkedintermediate server with which the PBX and one or more PMICs mayinteroperate, according to the preferred embodiment;

FIG. 16A is a flow diagram demonstrating the procedure for establishinga first category of CMS between calling parties, according to thepreferred embodiment;

FIG. 16B is a flow diagram demonstrating a first procedure forestablishing a second category of CMS between calling parties, accordingto the preferred embodiment;

FIG. 16C is a flow diagram demonstrating a first procedure forestablishing a third category of CMS between calling parties, accordingto the preferred embodiment;

FIG. 17 is a flow diagram demonstrating a call initiated from the PMIC,according to the preferred embodiment;

FIG. 18A is a flow diagram demonstrating an on-going telephonecommunication being transferred from a user PBX phone to an associatedPMIC, according to the preferred embodiment;

FIG. 18B is a flow diagram demonstrating an on-going telephonecommunication being transferred from PMIC to an associated PBX phone,according to the preferred embodiment;

FIG. 19 is a flow diagram demonstrating a PMIC automatically answeringan incoming call, according to the preferred embodiment;

FIG. 20A is a flow diagram demonstrating an incoming call beingautomatically forwarded by a PMIC, according to the preferredembodiment;

FIG. 20B is a flow diagram demonstrating a PMIC automatically respondedto an incoming call with an instant message, according to the preferredembodiment;

FIG. 21 is a functional block diagram of a PMIC with a plurality ofselectable SIP user agents, according to the second preferredembodiment; and

FIG. 22 is a CTI server with a plurality of PBX interfaces, according tothe preferred embodiment.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a PBX system operably coupled to a datanetwork. The PBX system 100 comprises a PBX 110 and a plurality of PBXphones 130-132, each phone being associated with a unique extensionnumber. The PBX 110 manages calls between the plurality of user phones131-133 and a set of trunk lines operably coupled to the Public SwitchTelephone Network (PSTN) 102 while supporting call forwarding betweenPBX phones, conference calling, call holding, voice mail, personalizedgreetings, and the like. The PBX system 100 is consistent with both newtelephone systems and a vast number of legacy telephone systemscurrently located at and operated by enterprises today.

Also operating within the enterprise is a data communications network150 embodied in or operably coupled to a local area network (LAN), awide area network (WAN), a metropolitan area network (MAN), the InternetProtocol (IP) network 104, or a combination thereof. The communicationsnetwork 150 operably couples a plurality of computers enabled with aPBX-Messaging Integration Client (PMIC) 140-142 distributed throughoutthe enterprise to each other and to the resources available through theWorld Wide Web using Ethernet and or the transmission control protocol(TCP)/IP protocol suite. Each of the PMICs 140-142 is generallyassociated with an individual enterprise worker. In most cases, anindividual's PMIC is located in the immediate proximity to theindividual's phone, thus giving rise to a logical association between auser PMIC and a user phone. The logical association between a PMIC, aphone, and a single user exist for a multiplicity of enterprise workersincluding a first user 120, second user 121, and third user 122, and soon.

In the preferred embodiment, the PBX 110 is enabled with a computertelephone integration (CTI) protocol, which refers to a signalingconvention by which the PMICs 140-142 may control and monitor PBXfunctions. In the preferred embodiment, the PMICs 140-142 are adapted toact as individualized clients for: (1) placing and answering PBX callswithout a PBX phone, (2) routing incoming call directed PBX extensionsto other devices, (3) forwarding calls away from PBX phones to otherdevices, and (4) placing calls on hold. In addition to receiving CTIcommands, the PBX or the CTI client associated thereto is also adaptedto transmit CTI messages upon occurrence of certain events, as isdescribed in greater detail below. Also in the preferred embodiment, thePMIC provides an interface to presence, instant messaging, documentexchange, desktop sharing and other capabilities typically resident inapplications such Microsoft's Real-Time Communications (RTC) Messenger.

FIG. 2A represents a functional block diagram of the PBX 110 with whichthe enterprise PMICs 140-142 interoperate. The PBX 110 generallyincludes a cabinet or backplane including one or more trunk interfaces220 for converting between the signal format and voice transmission ofthe PSTN 102 and the internal convention used by the PBX system 100, aplurality of PBX phone interfaces or line cards 222 providing aconnection to the user PBX phones 130-132, a CTI interface 224 fortransmitting and receiving CTI messages transmitted via the network 150,and a switch controller 202 for creating and managing voice circuitsbetween the trunk interfaces 220, line cards 222, and CTI interface 224.The switch control 202 is generally an element of a processing module200 embodying various call management services 204 including voice mail206 and other interactive voice response (IVR) systems 208, for example.

Signaling and voice communications between the PBX 110 and phones130-132 are conventionally performed using a digital protocol, althoughan analog protocol may also be employed. The digital protocol, referredto herein a private digital signaling and voice (PDSV) protocol,comprises a signaling convention that includes operation-codes used toexchange voice communications as well control signals. Although wellunderstood by those skilled in the art, PDSV protocols are generallyproprietary implementations and differ between vendors. The major CTIstandards are Telephony Application Programming interface (TAPI) andTelephony Services Application Programming Interface (TSAPI), as well asthe European Communications Manufacturers Association (ECMA) standardfor CTI, namely the Computer Supported Telecommunications Applications(CSTA) protocol.

Illustrated in FIG. 2B is a functional block diagram of a PBX processingmodule 200. The PBX processing module 200 in the preferred embodimentincorporates one or more software and or firmware components thatcooperate with switch control 202 to provide the PBX services 204. ThePBX processing module 200 may include an operating system 232, e.g.UNIX-based system or proprietary implementation, that in turn supports aCTI message handler 234 adapted to generate and respond to various CTIcommands in the manner set forth in greater detail below. When a CTIregistration command is used to associate a PBX with a PMIC, forexample, the CTI message handler 234 is adapted to transmit variousevent messages to the PMIC is response to various types of activitiesinvolving one or more PBX phones. In particular, the CTI handler 234 inthe preferred embodiment is adapted to transmit a CTI off-hook event toa registered PMIC in response to an off-hook signal received from theassociated PBX phone, transmit a CTI on-hook event to a registered PMICin response to an on-hook signal from the associated PBX phone, transmita incoming-call event to the PMIC associated with a PBX phone to whichthe PBX transmits a ring signal, a first call-answered event to the PMICwhen the associated phone is used to answer an incoming call, andtransmit a second call-answered event to the PMIC associated with thePBX phone used to place a call to another PBX phone when it is answered.

Illustrating in a FIG. 3 is a functional block diagram of a PBX phonetypical of user phones 130-132. The user PBX phone preferably includes ahandset and base unit 300 comprising a phone microprocessor module 310that enables incoming and outgoing calls. The phone microprocessormodule 310, in combination with the user interface logic 316, transmitsinput from the dial pad 314 and display relevant information at display312. The phone microprocessor module 310, in cooperation withcoder/decoder 322, conveys incoming voice signals to an audio userinterface (AUI) 320 speaker and outgoing voice signals received at anAUI 320 microphone to the PDSV interface 330.

Illustrated in FIG. 4A is a functional block diagram of a user's PMIC140-142. The PMIC 400 generally includes the hardware and softwarenecessary to provide access to and exchange voice and control signalswith another VoIP client including, in some embodiments, the PBX 110. Inparticular, the PMIC 400 comprises a processing module 410, display 440,tactile user interface 450 preferably including a keyboard, a AUI 460with sound card and speaker, and a network interface card (NIC) 470operably coupled to the data communications network 150.

The processing module 410 generally comprises hardware componentsincluding a central processing unit 412, computer memory 414, and randomaccess memory (RAM). As illustrated in FIG. 4B, the processing module410 may further comprise software and or firmware components including aPMIC controller 428 and a PMIC graphical user interface (GUI) 434 usedby the enterprise worker to monitor and configure the PMIC 428 as wellas bridge between the PBX domain and the VoIP domain. The PMIC 428 inthe preferred embodiment is adapted to monitor calls involving a PBXphone 130-132, intervene in calls under certain circumstances in amanner defined by the user, and establish media sessions on behalf of anenterprise worker in parallel with a telephone call.

Upon receipt of an incoming call, the PMIC 428 generally consultsrouting logic 430 to whether to forward an incoming call to another PBXphone or other device, for example, or respond with a messagetransmitted via the network 150. In the process of monitoring callsinvolving a user's PBX phone, the PMIC 428 may consult the subscribertable 432 to identify any Instant Messaging (IM) buddies in a contactlist of changes in the enterprise worker's telephonic presence. In somecircumstances, the PMIC 428 may also consult the concurrent mediasession (CMS) handler 434 to initiate transmission of an instantmessage, text chat or other voice and/or video media session between thePMICs of the users that are engaged in telephonic communication.

PMIC processing module 410 further comprises a CTI client 422,preferably a CTI protocol stack, and Real-Time Communications (RTC)client 426 running on top of an operating system 418 such MS WINDOWSalso by Microsoft Corporation. The CTI client 422 together with its CTIapplication programming interface (API) 420 provides the underlyingfunctionality used to implement the various call control functionalityembodied in the PMIC processing of the preferred embodiment. The RTCclient 426 with RTC API 426 provides support for the Session InitiationProtocol (SIP) used in some embodiments to enable the CMSs, as discussedin greater detail below.

Although the PMICs 140-142 in the preferred embodiment are personalcomputers, one skilled in the art will appreciate that any of a varietyof processing devices including desktop computers, laptop computers,personal digital assistants (PDA), Internet-enabled appliances, ormobile communication devices such as cellular phones may be adapted forpurposes of this invention.

Illustrated in FIGS. 5A and 5B is a state diagram characterizing the PBXwith which the preferred embodiment interoperates. The PBX 110 generallymonitors (state 502) the trunk lines to PSTN 102 as well as the internalphones 130-132. The operation of the PBX 110 characterized by the methodof FIGS. 5A and 5B generally falls into at least one of three differentcategories, namely, an outgoing call placed by a PBX user phone 130-132to a device external to the PBX 110, a internal call placed by a userphone 130-132 to another phone 130-132 within the PBX 110, and or anincoming call to a user phone 130-132 from a device external to the PBX110.

When a call is initiated by a user phone 130-132, an off-hook signal istransmitted from the phone to the PBX 110 with “digits” or dual-tonemulti-frequency (DTMF) signals representing a phone number or a PBXextension number. If the off-hook signal 520 is accompanied by the phonenumber to an external phone, the PBX 110 transitions to an externalcall-placed state 504, illustrated in greater detail in the externalcall process 600 of FIG. 6. Referring to FIG. 6, the PBX 110 identifiesthe digits representing external phone number received (step 610) fromuser phone and transmits (step 620) a connection request out to the PSTN102. Since the preferred embodiment of the PBX 110 is enabled with CTI,the PBX also transmits (step 630) off-hook plus dialed-number events tothe associated caller's computer 140-142 via the IP network 150. Theoff-hook and dialed-number events are messages used to notify a deviceregistered with the PBX, i.e. the caller's PMIC, that user phone hastransitioned from on-hook to off-hook to make the call. In the preferredembodiment, a client on the network 150 must have registered for thenotification at the PBX 110 using a registration event, e.g. a CTImessage, requesting notifications about the state of user phone 130-132identified by its extension number. Once registered, the PBX 110 directsthe off-hook plus dialed-number events registered client.

Referring again to FIG. 5A, if the off-hook signal 530 is transmittedfrom the PBX phone 130-132 is accompanied by an extension number of aPBX phone 130-132 within the PBX 110, the PBX transitions to an internalcall-placed state 506 illustrated in greater detail in the internal callprocess 700 of FIG. 7. Referring to FIG. 7, the PBX 110 identifies theextension number received (step 710) from user phone and transmits (step720) a ring signal to the call recipient's phone. The PBX also transmits(step 730) an off-hook plus dialed-number event with the recipient'sextension number to the caller's PMIC 140-142 via the IP network 150.The off-hook dialed-number event is preferably a CTI message, used tonotify the caller's computer that caller's phone is now in the off-hookstate as well as the particular extension dialed. In the preferredembodiment, the off-hook plus dialed-number event including theextension is transmitted indirectly from the PBX 110 through a CTIServer to the caller's computer, although the PBX may be used todirectly transmit the event to the caller's PMIC.

Referring to FIG. 5A, if the PBX 110 receives an answered signal 522from the external call recipient, the PBX transitions from the externalcall-placed state 504 to the PDSV voice communication state 510.Similarly, an off-hook signal 532 from the call recipient in response tothe internal call-placed 506 will also cause the PBX 110 to transitionto the PDSV voice communication state 510. The PDSV voice communicationstate 510 represents the processing necessary for the PBX 110 tomaintain voice communication, which may involve switch control 202operations such as analog-to-digital conversion and filtering, signalingand the like. If the call recipient answers using is a PBX phone, thePBX 110 may also send a call-answered event comprising the extension ofthe call recipient's PBX phone to the same registered client that theoff-hook plus dialed-extension event was sent. The PDSV voicecommunication generally continues until a calling or called party goeson-hook 528 and terminates the voice communication (state 516).

At nny time during the PDSV voice communications (state 510), the callin progress may be transferred to another device. If the PBX 110 isenabled with a VoIP protocol, for example, the PBX can transfer the callin response to a transfer command 534, e.g. a CTI message, with anidentifier specifying the device to which the voice communication is tobe redirected. If transferred to a VoIP client in the enterpriseworker's PMIC, for example, the PBX 110 attempts to establish a VoIPsession (state 512) and transfer the caller side of the communication toa VoIP device. In the session setup process 800 associated with thesession setup (state 512) illustrated in FIG. 8, the PBX 110 uses theidentifier from the transfer command received (step 810) to determine inthe transfer selection mode (step 820) where to forward the VoIP call. Atransfer command including a universal resource (URI) designating thecaller's PMIC, for example, causes the PBX 110 to issue (step 840) asession request message, e.g., a SIP INVITE, to a VoIP client in thecaller's PMIC. If the PBX 110 receives a SIP OK message 542 in responseto the session request message, the SIP OK testing (step 850) isanswered in the affirmative and SIP VoIP session (state 514) replacesthe prior PDSV communication between the caller's phone and PBX 110. ThePBX 110 may also be adapted to transfer calls to other resources (step830) including other PBX phones or external phones, for example.

After the SIP VoIP session is established (state 514), a participant inthe session may terminate the session and effectively end the call(state 516) by issuing a VoIP termination message such as a SIP BYEmessage 544. In the alternative, the participant may transfer the callback to a phone set (state 510) using a transfer command 536 includingthe appropriate phone extension.

Any time during the PDSV voice communications (state 510), the call inprogress may be placed on hold (state 518) by a hold PDSV operation codefrom the user's PBX phone or by a hold command 524 received by the PBX110 from the user's PMIC 428 via the network 150. Similarly, the callmay be taken off hold in response to the appropriate operation code oran un-hold command from the user's PMIC 428.

In addition to outgoing calls discussed above, the PBX 110 is alsoenabled to facilitate incoming calls. When a call 540 is directed to auser phone 130-132 from either another PBX user phone 130-132 orexternal PSTN line, the PBX 110 transitions into the initial callreceiving state 508. As illustrated the call receiving procedure 900 ofFIG. 9 associated with the initial call receiving state 508 of FIG. 5B,the PBX 110 transmits (step 910) the incoming connection request to therecipient's phone in the form of a ring signal. The PBX 110 in thepreferred embodiment also transmits (step 920) an incoming-call event,e.g. a CTI message, via the network 150 to notify the recipient's PMICof the connection request.

In the preferred embodiment, the incoming call may be answered at therecipient's PBX phone or by way of a CTI answer event received by thePBX 110 from the user's PMIC via the network 150. Upon receipt of anoff-hook signal 570 from the PBX phone, the PBX 110 transitions to thecall answered (state 552) illustrated in more detail in the callanswered process 1000 of FIG. 10. As shown, receipt of the off-hooksignal (step 1010) causes the PBX 110 to transmit (step 1020) a firstcall-answered event, e.g., a CTI message, notifying the recipient's PMICthat the call has been accepted at the associated PBX phone. If the callis also initiated from a PBX phone 130-132 within the PBX system 100,internal-caller testing (step 1030) is answered in the affirmative andthe PBX 110 generates a second call-answered event transmitted (step1040) to the caller's PMIC. The second call-answered event, e.g. a CTImessage, notifies the caller's PMIC when the call is answered by thecall recipient at the recipient's PBX phone or other device. SubsequentPDSV voice communications in state 554 are analogous to that discussedabove in context of PDSV voice communication state 510.

When the incoming call is answered at the call recipient's PMIC, the PBX110 generally receives an answer command accompanied by a transfercommand from the PMIC. The transfer command includes a URI designatingthe user's PMIC or a SIP user agent therein and the PBX 110 transitionsto the PBX's VoIP session setup state 556 consistent with the VoIPsession setup state 514 discussed above. If the session request messageissued by the PBX 110 is accepted, the PBX transitions into the PBX'sVoIP session (state 558) and the PDSV voice communication terminated.The recipient may subsequently transfer 586 the call between the PDSVvoice communication (state 554) and the VoIP session (state 558) in themanner described above.

If the transfer command 590 received while in the initial call receiving(state 508) includes a URI designating a phone, computer, or user agentother than that of the recipient, the PBX 110 effectively transfers thecall to the other device and returns to monitoring the phone status(state 502).

Illustrated in FIG. 11 is a state diagram characterizing the PMIC forextending the scope and control of a PBX system and extending the scopeof the presence sensing into the telephonic domain. The PMIC process1100 is preferably embodied in one or more user computers within anenterprise that may have a new or existing PBX system consistent withoperations discussed above. Each user computer 140-142 is adapted toexecute the PMIC process 1100, thereby making them PMICs. The pluralityof PMICs that interoperate with one another and the PBX 110 constitute aPMIC system. In general, there is a one-to-one relationship between aPMIC and an enterprise worker's PBX phone.

A PMIC generally monitors (state 1102) the IP network 150 for messagestransmitted by the PBX 110 as well as other PMICs in the enterprise. Themessages from the PBX 110 generally fall into one of two categories,namely, call-placed messages indicating that the PBX phone 130-132 withwhich the PMIC is associated is being used to place a call or incomingcall messages indicating that the associated PBX phone is receiving acall from either another PBX user phone or external line.

When the PBX phone associated with the PMIC is used to place a call, thePMIC receives the off-hook event 1130 generated by PBX 102 andtransitions into the on-phone presence-state (P-S) processing (state1104). The P-S processing (state 1104) is illustrated in greater detailin the on-phone P-S processing method 1200 of FIG. 12A. As illustrated,the PMIC consults (step 1210) its local subscriber table 432 to identifythe call recipient's presence-state subscribers. A P-S subscriber isparty that has registered to receive notice of a co-worker's onlinepresence and or telephonic availability. If one or more subscribers areidentified (step 1220), an on-phone event, e.g., a SIP message, istransmitted (step 1230) to each subscriber to indicate that the partywhose presence-state is being monitored has picked up the PBX phone.Referring to FIG. 11, the PMIC then indirectly monitors the telephoniccommunications (state 1106) by listening for any CTI events signifying achange in the ongoing telephonic communication.

When the PBX phone associated with the PMIC receives a call, the PMICreceives an incoming-call event 1140 and transitions to a call-routingmode (state 1110) in which the PMIC consults its routing logic 430. Therouting logic 430 is customized by the user and prescribes the action tobe taken in response to an incoming call. In the preferred embodiment,the PMIC is adapted to perform one or more of the following: (1) permitthe incoming call to ring at the user PBX phone without intervention,(2) transfer the incoming call to the user's PMIC, (3) transfer theincoming call to another device. e.g., the user's cell phone, (4)transfer the incoming call to another PBX phone, or (5) transmit aninstant message to the caller. In the preferred embodiment, the user candefine individual call-routing rules that prescribe how to respond tothe incoming calls as a function of when the call is received, thetelephone number or extension of the caller, the time of day and day ofweek, and the user's presence-state, for example.

If the routing logic 430 prescribes no action and the call recipientanswers the PBX phone, the PMIC receives an off-hook event 1142 from thePBX 110. The PMIC process 1100 advances to an on-phone presence-state(state 1112), as illustrated in FIG. 12A, as well as a concurrent mediasession (CMS) setup (state 1114). The on-phone presence-state (state1112) is consistent with the on-phone P-S processing (state 1104)described above. As illustrated in the CMS setup procedure 1300 of FIG.13 associated with the CMS setup (state 1114), the PMIC uses theextension and or phone number from the off-hook event received (step1310) to determine (step 1320) whether to initiate a media sessionconcurrently with the telephonic communication that began when the phonewas answered. A media session as used herein refers to a network-domaindialogue between the caller and call recipient established andmaintained separate from the telephonic communication. In the preferredembodiment, the concurrent media session may take one of more of thefollowing four forms: (1) a “message session” such as a SIP instantmessage, (2) a “text session” such as a SIP text chat session, (3) a“multimedia session” in which a SIP video or audio is exchanged, (4) adocument exchange session, or (5) computer GUI interface sharing such asa window-based operating system's “desktop sharing.”

Referring again to FIG. 13, the CMS testing (step 1330) is answered inthe affirmative if, for example, call recipient's PMIC is configured toautomatically attempt to initiate a CMS with all incoming PBX calls, orif the incoming call is from a PBX extension included in a group of oneor more numbers pre-selected or otherwise approved by the callrecipient. The selection of the type(s) of CMS(s) to be established aredetermined from user-defined CMS configuration parameters maintained bythe call recipient's PMIC handler 434. A CMS configuration parameter maybe set with a default value so that a text chat session or a videosession, for example, is automatically established in response to atelephone call. Independent of the initial session type, either user maythen manually escalate to a supplemental CMS including document share,screen share mode, or video session, for example. The one or more CMSsare initiated with a session request, e.g., a SIP message, directed fromthe recipient's PMIC to the caller's PMIC or other SIP conferencecalling center, e.g., a multi-point control unit known to those skilledin the art. If the session request is accepted with a SIP OK message,the session-request-answered testing (step 1360) is indicated in theaffirmative and the media session launched (step 1370) between the PMICsof the caller and recipient. In the preferred embodiment, the CMS may bemaintained or terminated separate and independent of the telephoniccommunication. Alternately, the CMS sessions could be terminated withthe telephone communication session ended.

Referring again to FIG. 11, the PMIC process 1100 proceeds to passivelymonitor (state 1106) the network 150 for any events signifying a changein the ongoing telephonic communication. When the phone is hung up, forexample, the PBX 110 transmits an on-hook event 1136, e.g. a CTImessage, to the recipient's PMIC that causes the PMIC process 1110 totransition to the off-phone P-S processing (state 1108). In theoff-phone P-S processing of FIG. 12B, associated with the phone P-Sstate 1108, the PMIC consults (step 1250) its local subscriber table 432to identify the call recipient's current presence-state subscribers. Ifone or more subscribers are identified, the subscriptions testing (step1260) is answered in the affirmative and each subscribers sent (step1270) an P-S status event, e.g., a SIP message, indicating theavailability status of the call recipient immediately prior to goingoff-hook to answering the call. In an alternate embodiment, theavailability status sent to each subscriber is on-line status.

Apart from the monitoring function (state 1106), the PMIC in someembodiments is also adapted to issue commands to the PBX 110 to alterthe telephonic communication involving the associated PBX phone. In thepreferred embodiment, the caller may alter the ongoing telephoniccommunication by taking one of the following actions: (1) terminate thecall, (2) place the call on hold, (3) transfer the call, or (4)establish a conference call with one or more additional parties. Theuser may terminate the call from the PMIC by issuing a terminate command1162, e.g. a CTI message, that instructs the PBX 110 to end (state 124)voice communications with the user' PBX phone. The user may also issue ahold command 1134A, e.g., a CTI message, to temporarily discontinue thevoice communications, after which the PMIC process 1100 resumespassively monitoring (state 1106) the PBX 110. An analogous release-holdcommand 1134B may be issued by the user from the PMIC to remove the holdand enable voice communication.

Prior to ending the call, the user may also transfer the call from thePBX phone to another device by issuing a transfer command to the PBX110. Depending on the identifier—URI, phone number, or extension—the PBX110 may transfer the call to the user's PMIC, the user's cell phone, oranother PBX extension, for example. When transferred by command 1144 tothe user's PMIC, the PMIC process 1100 transitions to the PMIC sessionsetup (state 1116) in which the PMIC and PBX 110 exchange SIP INVITE andOK messages necessary to establish a VoIP session (state 1118) toreplace the telephonic communication. While in the PMIC VoIP session(state 1118), the user acting through the PMIC GUI 436 can issue a PBXphone transfer command 1148 to restore the telephonic communication(state 1106), issue a SIP BYE 1158 message to end the call (state 1124),or issue an external-device transfer command 1160 causing the PBX 110 toforward (state 1120) the call to any device specified by the user.

In addition to permitting an incoming call to be answered at the user'sPBX phone, the call routing logic 430 may be configured to cause thePMIC in the call routing mode (state 1110) to automatically respond withone or more of the following actions: (1) transfer an incoming call tothe PMIC session setup (state 1116), transfer or forward the call to anexternal device (state 1112), or (3) reply with a message to thecaller's PMIC using an Instant Message. In the preferred embodiment,routing logic 430 is configured by the user to direct calls depending onthe caller's identification, the time, and the date, for example.

The flow diagrams in FIGS. 14 through 20 discussed below illustratevarious aspects of the PMIC processing 1100 of the preferred embodiment.These figures are provided by way of example and not limitation.

Illustrated in FIG. 14 is flow diagram depicting the method ofdistributing telephonic presence-state notices in the PBX system 100.Prior to configuring a user's PMIC to perform P-S notification, a usergenerally transmits a registration command to the PBX 110 to associatethe user's PMIC with the user's phone extension. This causes the PBX 110to transmit subsequent event messages pertaining to the user's PBX phoneto the user's PMIC. The class of events transmitted by the PBX to a PMICgenerally includes, but is not limited to: off-hook plus digits events,off-hook plus extension events, extension-dialed events, transferevents, incoming-call events, and answer events. In the followingexamples illustrated in FIG. 14 through FIG. 20B, the first user PBXphone 130 is identified by extension number x1234, the first user PMIC140 identified by URI 1234@proxy.com, the second user PBX phone 131 isidentified by extension number x5678, and the second user PMIC 141identified by URI 5678@proxy.com.

The registration command 1402 causes the PBX 110 to send to the firstuser's PMIC various CTI events relating to the first user's phone 130.The registration command 1402 may require that the first user 120 entera user identifier and password, although other forms of authenticationmay be implemented. Similarly, the PBX 110 is able to associate CTIcommands from this first user's 120 PMIC 140 with the phone 130extension.

At some later point in time, when the first user 120 picks up the phone130, an off-hook signal 1404 is relayed by the PBX 110 to the first userPMIC 140 in the form of an off-hook event, preferably a CTI off-hookmessage 1406. Receipt of the CTI event stimulates the PMIC 140 toautomatically change the presence-state for the first user to “on-phone”state. As prescribed by the on-phone presence-state processing 1200, thePMIC 140 consults (method 1200) its subscriber table 432 and transmits anotify message 1408, 1410 to all subscribers 121, 122 by way of theassociated PMICs 141, 142. The notify message is preferably a SIPon-phone message advertising the change in the first user's telephonicavailability.

When the first user completes the call, the on-hook signal 1412 from thefirst user phone 130 causes the PBX 110 to send the first user's PMIC140 an on-hook event 1414, preferably a CTI message. As prescribed bythe off-phone present state processing 1250, the PMIC 140 consults(method 1250) the subscriber table 430 and notifies all subscribers 141,142 of the change in the presence state by way of a SIP notify messages1416, 1418. In the preferred embodiment, the presence state indicated bythe SIP notify messages 1416, 1418 is the presence state that existedjust prior to the placement of the call. In an alternative embodiment,the presence state sent when the user goes off-phone may be “on-line”notice. The selection between the two embodiments might be auser-manageable setting.

One skilled in the art will appreciate that the linkage between the PBXphone operation and the presence state is performed entirely within theassociated PMIC endpoint itself. Moreover, the presence-state for theuser is changed automatically based on receipt of a CTI event withoutthe user manually changing his or her presence state via GUI interactionor other manual input. A principal advantage of this method of presenceintegration is that it can completely coexist and fully interoperatewith all other presence servers, presence collection/distributionservers, and any other SIP proxy servers that might be operationalwithin the network 150. The proposed method is also highly scalable,since it each PMIC is only responsible for the presence management ofits associated user PBX phone.

In some embodiments, the PBX 110 is both the source of CTI events andrecipient of CTI commands. One skilled in the art will recognize,however, the a PBX may employ a separate and external CTI server (notshown) that provides fan-out capability, user authentication, and otherCTI management tasks, as well as protocol translation between the PBXand the CTI client, for example.

Illustrated in FIG. 15 is a flow diagram demonstrating the use of anetworked intermediate server with which the PBX and one or more PMICsmay interoperate. The CTI server 1502 is adapted to relay messagesbetween the PBX 110 and one or more PMICs using CTI and/or eXtensibleMarkup Language (XML) protocols between the CTI server 1502 and the oneor more PMICs 120, 121. The proxy server 1502 relays CTI messagesbetween the CTI server 1502 and the PBX 110 using the CSTA CTI protocol,for example. Other protocol translations might also be possibleincluding, but not limited to, HTTP using Get or Post messages via adedicated IP socket, or SIP using textual information transmitted withSIP MESSAGEs sent between the CTI server 1502 and a PMIC.

As illustrated in FIG. 15, a first user PMIC 140 transmits aregistration command 1510, preferably a CTI or XML message, to the CTIserver 1502. The registration command 1510 comprises the extensionnumber of the first user phone 130 and enables the CTI server 1502 tocreate an association between the first user PBX phone 130 and the firstuser PMIC 140. When the first user phone 130 is used to place a call oranswer a call, the PBX 110 relays the off-hook signal 1512 to the CTIserver 1502 in the form of a CTI off-hook event 1514. The server 1502,in turn, forwards the CTI/XML off-hook event 1516 to the first user PMIC140. Reception of CTI off-hook event 1516 stimulates a change in firstuser's presence state that is propagated to any subscribers via anoff-phone notification event 1518, e.g., a SIP message. Similarly, anon-hook signal 1520 is transmitted to the CTI server 1502 in the form ofa CTI on-hook event 1522, then transmitted to the first user PMIC 140 inthe form of CTI/XML off-hook event 1524. The first user identifies (step1250) the presence state subscribers to be sent a SIP notify event 1526.One skilled in the art will appreciate that the presence statemanagement in the one or more PMICs of FIG. 14 is functionallyequivalent to those in FIG. 14, independent of whether the eventmessages originating from the PBX 110 are sent directly to the PMICs orindirectly via the CTI server 1502.

Illustrated in FIG. 16A is a flow diagram demonstrating the procedurefor establishing a first category of CMS between calling parties. Inthis example, a CMS in the form of a SIP session is automaticallyinitiated between a caller and recipient in the PBX system 100 inresponse to a telephone call. For purposes of demonstration, let thefirst user phone 130 have extension number x1234 and the second userphone 131 have extension number x5678. When the first user 120 depressesDual Tone Multi Frequency (DTMF) keys on the PBX phone 130 to call thesecond user 130, an off-hook signal 1602 comprising the call recipient'sextension is transmitted to the PBX 110. In addition to the ring signal1606 transmitted (step 720) to the second user's phone 131, the PBX 110also generates (step 730) an extension-dialed event 1604 to the caller'scomputer, PMIC 140, as notice that a call has been placed to theextension number x5678. Similarly, the second user's PMIC 141 isnotified via the incoming-call event 1608 of the incoming call fromextension x1234.

If the incoming call is answered with off-hook signal 1610, the PBX 110puts the first user phone 130 and second user phone 131 in telephonicvoice communication 1616. The CTI-enabled PBX 110 also responds to theoff-hook signal 1610 with a first call-answered event 1612 transmitted(step 1020) to the second user's PMIC 141 as well as a secondcall-answered event 1614 transmitted (step 1040) to the first user'sPMIC 140.

In response to the first call-answered event 1612, the second user'sPMIC 141 automatically initiates (step 1650) a media session, preferablya SIP chat session, concurrent with the telephonic voice communication1616. The process of initiating (step 1650) the media session is setforth in greater detail in CMS setup 1114 of FIG. 13. In this example,the media session is a SIP session including a simple SIP:MESSAGEmessage sent from second user's PMIC 141 to the first user's PMIC 140.In order to generate this SIP message 1620, in the preferred embodiment,the second user's PMIC 141 derives the SIP URI of the first user's PMIC140 in accordance with a SIP dial-plan. The dial-plan associates anextension, e.g., abcd, included in an event message with a SIP URI,e.g., SIP:abcd@someproxy.com. In this manner, the second user PMIC 141extracts the extension number 1234 from the incoming-call event 1608 andgenerates a SIP MESSAGE transmitted to SIP: 1234@proxy.com. Othersuitable dial-plans that allow the call recipient's PMIC to deduce thecaller's URI from the calling extension are also possible. For exampleanother dialing plan might associate extension 1234 withSIP:user91234@proxy.com where user 1234's PMIC has this SIP URI. Afterthe SIP exchange is completed with SIP OK 1622, SIP text messagingwindows are open on both first user's PMIC 140 and second user's PMIC141, thereby allowing the first user 120 and second user 121 to textchat with one another concurrent with the voice communication 1616. Oneskilled in the art will appreciate that there is no need for the firstuser 120 or second user 121 to appear on each other's contact lists, nora need for either user to lookup an IP address or SIP URI. Instead, theSIP session is established automatically based on the PBX call.

Illustrated in FIG. 16B is a flow diagram demonstrating a secondprocedure for establishing a CMS between calling parties. In thisexample, the various signals, CTI event messages, and SIP messages inFIG. 16B are replicated from FIG. 16A beginning with the off-hook plusdialed number signal 1602 through the SIP MESSAGE 1620. Here, however,the presence of the SIP MESSAGE 1620, and the corresponding SIP: OK, hasestablished a line of communication between first user 120 and seconduser 121 that may be exploited to open additional forms ofcommunication. After the SIP session signified by SIP MESSAGE 1620 hasbeen between established, either the first user 120 or the second user121 may escalate the interaction to other forms of supplemental CMSusing built-in capabilities of RTC, for example. In the preferredembodiment, either call participant may establish a supplemental CMS,e.g., a document exchange or a screen sharing session, that runs inparallel to the SIP:MESSAGE 1620. The supplemental CMS 1624 may bemanually selected (step 1652) by a user via the user's PMIC GUI 436 orother form of selection input device.

Illustrated in FIG. 16C is a flow diagram demonstrating a thirdprocedure for establishing a CMS between calling parties. Here, thevarious signals, CTI event messages, and SIP messages are replicatedfrom FIG. 16A beginning with the off-hook plus dialed number signal 1602through the SIP MESSAGE 1620. In this example, the first user 120 andsecond user 121 have desktop video cameras used by the CMS handler 434of each user's PMIC 140, 141 to automatically setup (step 1654) asupplemental CMS such as video session 1626 with the primary CMS session1620. The call recipient's CMS handler 434 automatically issues anadditional SIP INVITE containing video session description protocol(SDP) information. In the preferred embodiment, the video session is auser-manageable setting, thereby allowing a call recipient to configurethe CMS handler 434 to: (1) automatically enable and start the camerafor every call, (2) fully disable the camera to prevent the camera fromstarting, (3) manual enable the camera to start at the discretion of theuser, or (4) selectively enable the camera to start depending on thecaller identification, i.e., caller ID.

As illustrated in more detail below, the integration of a CTI clientcapability into a PMIC permits the user to execute standard telephoneset control functions from the individual's computer. In the preferredembodiment, the PMIC is adapted to transmit PBX call control commandsincluding, but not limited to, make-call commands to initiate a call,answer-call commands to accept an incoming call, hold-call commands totemporarily pause an on-going call at the PBX, transfer-call commands toredirect a call between the PBX phone and user PMIC or other device,conference-call commands to establish a call with three or more parties,and forward-call commands to direct a call to a device specified by theuser.

Illustrated in FIG. 17 is a flow diagram demonstrating a PBX-supportedcall initiated from a PMIC. First, the user enters a destinationtelephone number into the user's PMIC GUI and activates a make-callroutine in the PMIC controller. The PMIC issues a make-call command 1702that causes the PBX 110 to issue a ring signal 1704 to the user's phone130. After the handset is picked up and an off-hook signal 1706transmitted, the PBX 110 places the call to the destination numbercorresponding to second user phone 131, for example, via a ring signal1708. When the second user phone 131 is answered and an off-hook signal1710 transmitted, the parties are enabled for telephonic voicecommunications 1712, 1714. In another embodiment, the caller's PBX phone130 automatically enters a hands-free speakerphone mode and therecipient called immediately after the destination number is entered atthe PMIC 140.

Illustrated in FIG. 18A and FIG. 18B are flow diagrams demonstrating anon-going communications being transferred between a user PBX phone andthe associated PMIC. In this embodiment, the PMIC is adapted tointeroperate with a PBX 110 enabled with SIP or other VoIP protocol inaddition CTI client functionality. This PBX system, referred to as aSIP-PBX, has native SIP capabilities including the ability to make andreceive SIP voice calls.

As illustrated in FIG. 18A, an enterprise worker may transfer anon-going call on the PBX phone to the user's PMIC. At any time during atelephonic voice conversation 1802, 1804 between the first user phone130 and the second user phone 131, a user may transfer the call from tohis or her PMIC 141 by issuing a PMIC transfer command 1806, preferablya CTI message, comprising the identifier of the device to which totransfer the call. In the case of a PMIC 141 enabled with a SIP useragent, the transfer command 1806 may include the SIP URI used by the PBX110 to execute a call transfer to the PMIC SIP voice client. When theSIP INVITE 1808 to 5678@proxy.com is accepted by the PMIC 141 by meansof a SIP OK message 1810, the PBX 110 bridges the first leg of theconversation 1814 with the first user phone 130 in the PDSV domain withthe second leg of the conversation 1816 with the second user PMIC 131 inthe SIP domain. In the preferred embodiment, the SIP URI is derived fromextension number of the user phone with which it is associated.

As illustrated in FIG. 18B, the second user 121 may at any time transferthe SIP domain call 1816 directed to the second user PMIC 141 back tothe second user PBX phone 141 A PBX phone transfer command 1818, e.g. aCTI message, comprising the 110 second user's phone extension, numberx5678, is issued by the second PMIC 141 to the PBX 110. Upon receipt,the PBX 110 terminates the SIP session with a SIP BYE message 1820 andenables the PDSV voice communication 1826 between the PBX 110 and thesecond user phone 131.

As illustrated in FIG. 19, a PMIC may also be used to answer an incomingcall destined to a PBX phone independently of the user's PBX phone. Inresponse to an incoming call 1902, the PBX 110 in the preferredembodiment transmits a ring signal 1906 an incoming-call event 1908,e.g. a CTI message, to the call recipient's PMIC 141. The second user121 may then click an answered button in the PMIC GUI causing it toissue an answer command 1910 and transfer command 1912. The transfercommand 1912 comprises the identification of the device to which thecall is to be forwarded. The identification of the PMIC 141 is the SIPURI, SIP:5678@proxy.com. In response, the PBX 110 issues a SIP INVITEmessage 1914, to which the PMIC 141 automatically responds with a SIP OKmessage 1916. The subsequent conversation between the caller 120 andrecipient 121 includes PDSV domain voice 1920 between the caller 120 andSIP PBX 110, and SIP domain VoIP 1922 between the SIP PBX 110 andrecipient's PMIC 141.

Illustrated in FIG. 20A and FIG. 20B are flow diagrams demonstrating anincoming call to a PBX phone being automatically processes by anassociated PMIC without user intervention. In FIG. 20A, the PMIC answersan incoming call to a user's PBX phone and then forwards the call toanother device previously specified by the user.

In response to an incoming call 2002, the PBX 110 in the preferredembodiment transmits ring signal 2006 to the second user phone 131 andan incoming-call event 2008 to the call recipient's PMIC 141. Uponreceipt of the incoming-call event 2008, the second user PMIC 141implements call routing processing (state 1110) that dictates how thiscall is to be treated. If the call routing logic 430 of FIG. 4Bindicates that the call should be transferred to another device, thesecond user PMIC 141 issues an answer-call command 2010 preventing thePBX 110 from forwarding the call in accordance with its no-answerprocedure, e.g. voice mail 206. The second user PMIC 141 also issues tothe PBX 110 a call-transfer command 2012 identifying the destinationdevice to which the call is to be forwarded, e.g., device ABCD. Thedestination device may be another PBX extension, a PSTN telephone, or aSIP user agent.

The call routing logic 430 in the preferred embodiment comprisesuser-managed preferences include forwarding criteria and the action tobe taken when the forwarding criteria are satisfied. These criteria mayinclude the phone number or extension of the calling party and thetime-of-day and date, for example. The call routing logic 430 maydictate that (1) on Wednesday evenings the call should be answered andtransferred to PBX phone extension number x6789, on (2) Thursdayevenings the call should be answered and transferred to John@acme.com,and (3) at all other times, the call is not answered by the PMIC,thereby allowing the PBX 110 to automatically forward to call voicemail206 if not answered.

The call routing logic 430 in some embodiments may also depend on thepresence state of its user. For example, if a user's presence state isset to “away,” determined either via manual operation or automaticallyin the absence of keyboard activity for a period of time, the callrouting logic 430 may be configured to forward to an incoming call tothe extension of an administrative assistance. Similarly, an incomingcall might be directed to the SIP user agent of another enterprisecolleague selected by the user, thereby providing an alternative pointof contact while the user is unavailable or out of the office. In thepreferred embodiment, the call routing logic 430 is in the form of ascript created by the user, although it may also be configured via agraphical and or menu-based interface on the PMIC GUI 436.

The call routing logic 430 of a PMIC in some embodiments also includesthe SIP text messaging and document transfer capabilities as part of thecall treatment for incoming and outgoing calls at the PBX phone.Illustrated in FIG. 20B is a flow diagram demonstrating an instantmessage being transmitted by a PMIC in response to an incoming call. ThePBX 110 responds to incoming call 2002 with ring signal 2006 and anincoming-call event 2008 sent to the call recipient's PMIC 141. Uponreceipt of the incoming-call event 2008, the second user PMIC 141implements call routing processing 1110 that dictates how this call isto be treated. When configured accordingly, the second user's PMIC 141transmits an instant message 2020 from the user's PMIC to the caller'sPMIC 140. The caller's SIP URI, SIP: 1234@proxy.com, is derived from thecaller's extension, number x1234, learned by the second user's PMIC 141from the preceding incoming call event 2008.

The instant message may include a standardized greeting or a customizedInstant Message including information specifically intended for thecaller about. A person may, for example, generate a personal messageincluding the anticipated return time or an alternate contact number.Similarly, the call routing logic 430 in some embodiments is adapted totransmit a document that may contain text, graphics, spreadsheet, orother information of interest to the caller in response to an incomingcall directed to a specific PBX extension.

After the instant message 2020, the incoming call may further processedin any number of ways defined by the call routing logic 430. In thisexample, the second PMIC 141 causes the PBX 110 to transfer the incomingcall to device ABCD using transfer command 2022.

In some embodiments, the caller's PMIC may also be configured to respondto the call recipient's instant message with another instant messagesent to the call recipient's PMIC 141. For example, when the second user121 receives a telephone call from extension number x1234, the callrouting logic 432 generates the appropriate URI and sends an instantmessage to SIP:SecondUser@pda.com to inform the second user 121 that thefirst user phone 131, i.e., extension number x1234, had called. The callrouting logic 430 may be tailored to inform a call recipient of the calland the time of the call.

The call routing logic 430 may also be configured to automatically sendan instant message when an outbound call is placed from the PBX phoneassociated PMIC. A specific SIP emergency message, for example, may besent to a pre-selected SIP user when the Emergency 911 number is dialed.

Illustrated in FIG. 21 is a functional block diagram of a user PMIC witha plurality of selectable SIP user agents. In addition to Microsoft'sRTC SIP client 424 and a CTI client 420 discussed above, a PMIC 2100 mayfurther include one or more additional SIP instant messagingapplications such as a SAMETIME client 2102 by IBM Lotus Corp. and/orany other commercial SIP User Agent Client The user may select one ofthe plurality of SIP client via PMIC GUI 436, for example, by entering auser-selectable parameter causing the SIP/IM selection module 2110 touse the selected SIP client for subsequent IM exchanges. To aid in theselection, the various features supported by each individual SIP clientmay be indicated as present or not present, or selectable andnon-selectable. As with other GUIs, the features that are not present ina particular client may be indicated by representing the feature ingreyed-out text or icon form. To the degree that two or more SIP clientssupport common functionality, in the preferred embodiment the userexperience is identical and independent of the SIP client selected.

Illustrated in FIG. 22 is a CTI server with which the present inventionmay be made to interoperate with one of a plurality of different typesof PBX systems. The CTI server 2200 in this embodiment comprises aplurality of PBX interfaces from which the network administrator maychoose. Using the PBX selection 2208, for example, the systemadministrator may configure the CTI server 2200 to use either PBX-Ainterface 2202, PBX-B interface 2204, or PBX-C interface 2206, dependingon the hardware and vendor requirements of the PBX 110. CTI server 2200capable of communicating with multiple types of PBXs using a singlecommon CTI interface 2210 protocol to/from a CTI client are availablefrom Genesys Telecommunications Laboratories, Inc. of San Fransisco,Calif., for example. In this manner, the PMIC is generally able toprovide the functionality of the several embodiments in a mannerindependent of the type PBX system or vendor.

Although the description above contains many specifications, theseshould not be construed as limiting the scope of the invention but asmerely providing illustrations of some of the presently preferredembodiments of this invention.

Therefore, the invention has been disclosed by way of example and notlimitation, and reference should be made to the following claims todetermine the scope of the present invention.

1. A private branch exchange (PBX) call control method for a firstcomputer interface operatively coupled to a system comprising a PBX anda first PBX phone, the PBX call control method comprising the steps of:receiving from the PBX a first message indicating the presence of atelephone call associated with the first PBX phone; and transmitting tothe PBX a call control message.
 2. The PBX call control method of claim1, wherein the first message is a CTI event message.
 3. The PBX callcontrol method of claim 1, wherein the first message is a call holdcommand instructing the PBX to place the telephone call associated withthe first PBX phone on hold.
 4. The PBX call control method of claim 1,wherein the first message is a call forward command instructing the PBXto transfer the telephone call associated with the first PBX phone tosecond phone.
 5. The PBX call control method of claim 4, wherein thesecond phone is a second PBX phone.
 6. The PBX call control method ofclaim 4, wherein the second phone is a voice-over-IP client.
 7. The PBXcall control method of claim 6, further comprising the steps of:transmitting to the PBX a first message for forwarding the telephonecall associated with the first PBX phone to a voice-over-IP client;establishing a voice-over-IP session between the PBX and thevoice-over-IP client; and directing the telephone call to first PBXphone to the first computer interface via the voice-over-IP session. 8.The PBX call control method of claim 1, wherein the call control messageis an answer call command instructing the PBX to answer the telephonecall using a second device.
 9. The PBX call control method of claim 8,wherein the second device is a second PBX phone.
 10. A private branchexchange (PBX) call control method for a first computer interfaceoperatively coupled to a system comprising a PBX and a first PBX phone,the PBX call control method comprising the steps of: transmitting to thePBX a group of one or more messages comprising: a command to the PBX tomake a call to a first PBX phone, and a telephone number of the firstPBX phone; and receiving a first message indicating the hook state ofthe first PBX phone.